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Abstract: "Elearning2.0" promises to harness the power of three of today's most disruptive 
technologies: social software, eleaming, and Web2.0. Our own work in this disruptive space takes as 
a starting premise that social networking is critical for learning: finding the right person can be more 
important than ‘scouring the web for an answer’, particularly when hand-holding or other explanatory 
services are required. Moreover, it ’feels good' to know that others are around! With this in mind, we 
have taken our older BuddySpace tool, and created a new tool we call MSG, which is simpler, 
available as Open Source, and integrates cleanly with a number of other services, including Moodle 
and Google Maps. 


Keywords: Social presence, location, eleaming, social networking, presence, enhanced presence, 
presence discovery, Openleam, BuddySpace, MSG 


1 Introduction: disruptive technologies for the learner 

"Eleaming2.0" promises to harness the power of three of today's most disruptive technologies: social 
software, eleaming, and Web2.0. Our own work in this dismptive space takes as a starting premise 
that social networking is critical for learning: finding the right person can be more important than 
‘scouring the web for an answer’, particularly when hand-holding or other explanatory services are 
required. We know from Whitelock et. al. (2000) that presence awareness increases emotional well- 
being, and from Nardi et. al. (2002) that users benefit from knowing who else is around via presence 
and messaging tools; so generally it ’feels good' to know that others are around! 


The notion of peer-group interactions is critical to many learning interactions. Johnson and Johnson 
(1986) and numerous others have described the benefits that accme from activities such as joint 
problem solving and related peer interactions that take place in the presence of other students. But in 
an e-leaming situation, what exactly does it mean to be ‘in the presence of other students’? The notion 
of ‘presence’ must therefore be extended, because the other students, and indeed the teacher or tutor, 
may not be physically present: instead they are only virtually present. Our belief is that simply being 
able to see the other person, although obviously useful, is neither necessary nor sufficient to impart a 
sense of presence: more critical is the mental state that depends on knowing the other person is 
available, even at a distance, and this can be de-coupled from ‘visibility’. This mental state is crucial 
for what we called ‘ enhanced presence’ . We argued in Eisenstadt et al (2004) that enhanced presence 
could be of direct benefit to learners in informal settings by facilitating their conversations, especially 
at a distance. 
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With this in mind, we have taken our older BuddySpace tool (Vogiazou et. al. 2005), which provided 
instant messaging and maps, but was found by testers to be ‘over-geek-ish’ to use, and created a new 
tool we call MSG, which is simpler, available as Open Source, and integrates cleanly with a number of 
other services, including Moodle and Google Maps. Below we describe our initial design principles 
for BuddySpace and how we extended them to MSG, and illustrate the nature of the MSG 
environment. 


2 From BuddySpace to MSG 

BuddySpace was our original geographically-enhanced instant messaging environment, based upon the 
same Jabber/XMPP messaging protocol now made popular by GTalk and Meebo. The essence of 
BuddySpace was to provide the user with a personal ‘dashboard’ or ‘radar screen’ so that he or she 
could observe the availability and ‘interaction state’ of colleagues, fellow students and friends 
worldwide in a manner that was based on the following design principles: 

• immediate yet non-intrusive: real-time updates (e.g. presence changes, news alerts, etc.) 
pushed instantly to users rather than pulled in by request 

• scalable: we have to provide ways to indicate the presence of potentially enormous numbers 
of people 

• interoperable: with several hundred million users of the ‘Big Four’ (AIM/ICQ/MSN/Yahoo!), 
it was crucial that any approach allowed interoperability with systems to which our users 
already subscribed 

• cross-platform and open: we need to service a community not only on Windows, 

Unix/Linux, or Mac configurations, but eventually on PDAs and mobile phones - we therefore 
developed BuddySpace entirely in Java and keep it as open source, available at 
SourceForge.net. 

• XML-literate: for intelligent applications, communication transport needs to be about more 
than just string-transmission; another reason we adopted Jabber is that it is based entirely on a 
generic XML transport architecture, ideally suited for enhancing it with semantics in the future 

• Geo-aware: we felt strongly that location matters, and wanted to display the whereabouts of 
friends and colleagues by overlaying their presence statuses on custom maps, including office 
and building plans when appropriate. 


BuddySpace was actively developed over a number of years (from 2002 to 2007) and the client 
remains in active use. An empirical study reported in Vogiazou et al (2005) demonstrated that map 
locations helped enhance the sense of group belongingness. Nevertheless, feedback from users 
indicated that the application was still difficult to deploy without key champions on site to assist. 
Also, the prevailing move over the last few years to web-based (web 2.0) applications indicated to us 
that significant benefits could be gained by extending our original thinking and simplifying the tool 
even further. The result, called MSG, is the web-based incarnation of BuddySpace and retains the 
functionality necessary to meet the desirable properties just described. The key differences between 
BuddySpace and MSG are summarised in table 1 . 
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BuddySpace 

MSG 

Java application 

Web based - JavaScript (AJAX) 

Self-contained (monolithic) 

Distributed (web-services) 

Download & install 

Browser based (no installation) 

Custom maps 

Google Maps 

100's of features 

Functionality kept to the basics 


Table 1: key differences between BuddySpace and MSG 


The development of MSG also allowed us to leam from our experiences with BuddySpace in a number 
of distinct areas. Firstly, we had learned from BuddySpace that adding many features does not 
necessarily help the user, because it becomes difficult to design a clean and simple user interface. Also, 
the study of Vogiazou et. al (2005) showed that many of these features were rarely used. From the data 
about the usage of features of BuddySpace, MSG was able to take the feature set known to be actually 
used. An example of this is “group chat”, although an often requested feature, evidence shows that it is 
rarely used and so was omitted from MSG.. 

Secondly, using a distributed, service-based architecture makes it much easier for us to embed third 
party applications, of which embedded maps are a good example. In BuddySpace, the presence maps 
used maps which had been designed specifically for that purpose, making it difficult and time 
consuming to update. Whereas in MSG, we have used the Google Maps API to embed presence 
mapping facilities. 

The interface to MSG has been kept deliberately clean and simple - as figure 1 shows - users simply 
click on the name of the user, or their presence icon if they are online, to instantiate a chat session. 
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Figure 1 : interface to MSG, showing the users contact groups 


In addition to being able to find users based on group membership, MSG users can also find their 
contacts based on geolocation. Through the analysis of an Open University course discussion forum, 
we found that nearly 20% of the first 1000 postings were related to finding out whether or not there 
were other students in the same geographical area, so the ability to identify and locate fellow learners 
“in one’s region or close by in order to form a self support group is invaluable” (Vogiazou et. al. 
2005). 


Unlike the custom maps of BuddySpace, we wanted to foster interoperability via mashups with other 
existing technologies, the most obvious one being Google Maps. With the MSG Presence Map (see 
figure 2)., users can pan and zoom around the map to see where their contacts are currently located. We 
have made it easy for users to update their location, using another 3rd party service, Geonames 
(http://www.geonames.org), to geocode the textual location entered by the user. This is another 
example of how the distributed architecture of MSG has enabled us to easily make use of external 
web-services. 
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Figure 2: Google Maps integration 

Other facilities in the MSG presence map include the ability to search for users, based on their name or 
contact group and being able to filter the markers displayed on the map; the markers can be filtered by 
contact group or by search results. 


A common problem with many Google Maps applications is that when there are many markers to 
display, they can end up being displayed on top (or very close) to each other, making it hard to identify 
individual markers, and from a performance perspective, too many markers on a map (over 
approximately 100) can slow Google Maps down significantly, having a negative impact on the user 
experience. In order to address this problem, MSG presence maps uses a clustering algorithm, to avoid 
markers being overlaid on top of each other. As the users zooms the map in, the markers break apart 
and on zooming out the markers recombine. So a marker on the map can represent a group of users, 
with the size of the marker indicating the number of users at a particular location. If at least one user at 
a location is online then the marker is green, otherwise gray. 

When a marker is clicked, a listing of all the users at the location is displayed, along with their 
presence status and an option to launch a chat conversation if the user is currently online. All the 
presence state information is live, negating the need for the user to refresh the page. 

The MSG Presence Map can be used as an alternative to, or in conjunction with the MSG contacts 
page (as shown in figure 1), giving the user a variety of ways to keep track of the presence state of 
their contacts. 

2.1 Integration with OpenLearn 

One of the key aims of OpenLearn is to "explore how best to make [high quality learning materials] 
freely accessible in an international web-based open content environment" ( OpenLearn project 
proposal) and in doing so "encourage the creation of non-formal collaborative learning communities". 
With Instant messaging (IM) being one of the most widely used social networking tools, integrating 
instant messaging into OpenLearn, with its potential for community building, peer-to-peer and 
collaborative learning, seemed natural. There is a huge range of instant messaging tools available (e.g. 
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AIM, MSN and GTalk). However they do not fit the bill for messaging in an educational context, 
where our background research on BuddySpace suggested that educational users liked the power of IM 
tools, but preferred the security, familiarity and 'feel-good' factor of an IM tool associated with an 
educational resource provider. MSG offers the openness and interoperability required to embed IM 
into OpenLeam, other IM systems can be fairly closed and would be difficult to integrate into a third 
party websites. 
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Figure 3: MSG Instant Messenger embedded in LabSpace. [A] The persistent OpenLeam 
‘Block’ that shows personal status, personal contacts, and all users currently logged in. [B] The 
MSG messenger itself runs in any browser, with standard browser tools hidden, and allows 
setting of ‘status’ via the three lights at the top, listing of group members and 1-1 chat after 
clicking on a user name, as shown in [C]. Geographical location (using Google Maps API) of 

users' contacts is the latest new feature [D] . 


The ability for integration into OpenLeam was one of the key factors in the decision to further develop 
MSG rather than using an existing IM system. MSG enables us to deeply embed and integrate users 
presence within the OpenLeam site. Whenever a user is logged in to the OpenLeam site, they are also 
automatically logged in to MSG, removing the need for the user to separately launch and log in to 
MSG. The MSG 'block' (as show in figure 4), which appears on most of the webpages in OpenLeam 
(the exception being the course content pages), displays the users current presence state, the number of 
their contacts currently online and the total number of users online. A small MSG presence map is also 
displayed, showing the locations of all the users currently online in OpenLeam. 
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Figure 4: MSG 'block' 


MSG uses information from the user’s OpenLeam profile to populate contact groups, this is necessary 
as users can only chat to each other if they share a group. Currently, the MSG contact groups are 
generated from a user’s course enrolments, so two users who have both enrolled on 'SI 03 - 
Earthquakes' for example will each be added to the 'SI 03 - Earthquakes' group. However we are 
looking at making the automatic contact group creation slightly more flexible (see the ’Future' section). 
MSG also uses the location entered on the users OpenLeam profde (on registering all users are 
required to provide a town or city and country) to populate the MSG Presence Map. 

MSG presence status is embedded throughout the OpenLeam site, wherever a user’s name appears, if 
the users are in the same groups, we also display their presence status. This is most noticeable in the 
fomms (as shown in Figure 5) where we can easily see who is currently online. The presence icons are 
clickable, giving the MSG standard single click to chat. This gives learners the opportunity to engage 
in spontaneous discussions with other users who share a common interest. 
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Figure 5: Showing presence status embedded in the OpenLeam website 


New message notifications are given in the page header as well as a small pop up window in the 
bottom right of the page (in a similar style to how GTalk displays new message notifications), giving 
the user instant notification that they've received a new message and the opportunity to engage a in 
chat conversation. The alerting of new messages needs to be a balance between being intrusive enough 
that the user will notice the alerts, but not so intrusive as to irritate the user. 

Privacy and security, on a number of levels, was an important factor we needed to take into 
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consideration when planning and implementing the integration of MSG into OpenLearn, especially 
with the inclusion of the users location on the presence map. By editing their OpenLearn profde (or 
when they first register), users are given the option to opt out of MSG altogether - in which case the 
data in the OpenLearn profile will not be replicated over to MSG. On registering with OpenLearn, 
users are required to provide a town or city and country, this is the data MSG uses to mark the users 
location on a map. The apparent lack of granularity in the location is actually a benefit for MSG, as 
using just the town is good enough for the purpose of displaying users on the presence map and for 
other users to find who is in their locality. It also avoids potential privacy and security concerns that 
would be raised if MSG were to mark users exact addresses on the map. The final privacy 
consideration was the storage of the chat conversations since the MSG server allows the option of 
storing all conversations. For the purposes of research and to be able to monitor the usage levels of 
MSG, we took the decision to record all chat conversations with users identities obfuscated. This 
obfuscation, rather than totally anonymisation, allows us to offer extra facilities to users such as the 
option to retrieve their chat history - which wouldn't be possible with total anonymised recording. This 
is in line with the facilities and options provided by almost all mainstream IM systems (e.g. MSN). 


2.2 MSG: just another Instant Messaging system? 

Although there are a large number of instant messaging systems and tools in use and readily available, 
there are a number of attributes that, in combination, make MSG distinctive: 

• It runs directly in a web browser environment, using AJAX, so no installation is required 

• It provides only the functionality that covers more than 90% of what our original BuddySpace 
users actually used: simple ‘online/away/do-not-disturb’ settings, lists of users, and click-to- 
chat. We have deliberately restricted the functionality in the interests of simplicity. 

• It implements a ‘single-sign-on’ capability so that users who log in to OpenLearn are 
automatically logged in to MSG. 

• It enables ‘presence everywhere’: any user’s ‘presence status light’ can be embedded within 
any other part of OpenLearn, such as a single comment in a discussion forum. 

• It includes an optional ‘desktop notification widget’ which allows users to receive a compact 
message alert in their system task-bar. 

• Where we know a user’s location (from their stored user profile) and have that user's 
agreement, MSG Presence Maps (built on the Google Maps API) allows large-scale zoom-able 
displays of online users' locations: the locations are automatically clustered in different sizes 
depending on the zoom factor, preserving the one-click-to-chat feature. 


We feel that it is the combination of these features that makes MSG distinctive, rather than any one 
individual feature. No other IM client can currently offer this combination: even GTalk (Google's own 
instant messaging tool) does not make use of Google Maps. We have been asked many times for 
additional functionality, for example group chat, but we have always resisted feature-creep, especially 
where functionality is already well catered for by other IM systems. 


So far we have seen the story of how MSG grew from the experiences of BuddySpace, how we have 
integrated MSG into OpenLearn and how MSG differs from other instant messaging systems. MSG 
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has been running in OpenLearn for just over a year now, from 25 October 2006 to date (Nov 2007), so 
now we'll take a look at our experiences so far of using MSG in OpenLearn. 


3 Experiences 

Initially, MSG was only integrated with the LabSpace part of OpenLearn (LabSpace is the 
experimental area of OpenLearn to allow researchers and educators to 'try things out'), and did not 
include presence maps. During this initial phase (from Oct 2006 to mid-May 2007) approximately 
4000 users registered with MSG (by registering on LabSpace and enrolling on a course) and 
participated in several hundred chat conversations. In May 2007 MSG was integrated into the 
mainstream OpenLearn site (LeamingSpace), which receives approximately 10 times the number of 
page hits to LabSpace, so the number of registered users significantly increased and now (November 
2007) stands at just over 17500 with several hundred more chat conversations having taken place. The 
MSG presence map was launched in May 2007 across both LabSpace and LeamingSpace. 

3.1 Usage 

Analysis of the chat conversation logs shows that the vast majority of MSG chat to be conversations 
about the MSG tool itself, what we would term 'meta-level-chat', rather than discussion concerning the 
OpenLearn materials and content ('object-level-chat'). Table 2 shows sample chat messages to 
demonstrate typical conversation messages: 


"Hello, I'm just trying to leam about Open Learn. It’s my first day. How are you getting on?" 


"Hi, just messenging you to test the system, it’s my first visit!" 


"hello..? hellooo-ooooo..??! is this thing on?" 


"testing., (hi... sorry to interrupt... just testing a few features., let me know if you receive this ok)" 


"Hi there- are you doing ddlOO too?" 


Table 2: sample chat messages 


This is entirely as we would expect since there are two central problems which preclude object-level- 
chat. 

Firstly, motivation: there is neither overarching guidance nor any self-evident motive that inherently 
embeds MSG interactions into any of the educational resources (e.g. “now do activity X which 
involves synchronous chat”). This is due to the nature of most of the materials in OpenLearn, which 
has been taken directly from standard Open University courses, so is very focused on individual as a 
lone learner, rather than group, collaborative or peer-to-peer learning. Hence the majority of 
OpenLearn content does not contain activities encouraging the use of collaborative tools. So the 
collaborative tools (including MSG), although freely available, may be seen as entirely optional. 

Another factor related to motivation is the fact that users have very little information about the other 
learners in their groups, for most learners the information available is limited to their name and an 
approximate location. Users may feel they don't have enough information about other learners in their 
groups to simply strike up chat conversations, for example, about other learners interests or how much 
of the course they have already completed. This is why we felt it important to deeply embed the MSG 
presence icons into the OpenLearn site, especially in the forums, where the forum posting content 
would give a reason and subject matter for learners to chat to each other. It all adds up to suggest that 
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chat interactions can only occur spontaneously and for no obvious mutual end, with limited motivation 
for the learner to use the chat. 

Secondly, critical mass: At any random moment, there is no one else ‘around’ in MSG, because there 
is not a sufficient number of users right now. Thus, even if there were anything of direct educational 
relevance to discuss, there is no one to discuss it with. Typically there are between 20 and 40 
registered users logged in to MSG (via OpenLeam) at any given time, but, given there are over 600 
courses in OpenLeam, a typical visitor may only have a maximum of 5 or 6 contacts online at any 
time. Also, these contacts may not be on the same course the learner is currently studying. This 
problem may be exacerbated by the fact that users can access all the OpenLeam material without 
registering, therefore these users will never receive an MSG account, so nor appear to other MSG 
users. We're not suggesting that OpenLeam material should only be available to registered users, but 
perhaps we’re not making the benefits of registration compelling or obvious enough for users to take 
the time to register. 

3.2 Peer Presence Discovery 

The presence map (item [A] in figure 3) is designed to foster peer presence discovery. This in turn is 
intended to facilitate an ad hoc learning experience: not unlike what happens throughout our lives! 
From our server logs we know that the Presence Map (figure 2) is now the primary launchpad for 
MSG and has a higher hit rate than the standard contacts page (figure 1). 

3.2.1 Tyranny of the Browser 

A web-centric approach for an instant messaging client, with the limitations of users' browsers, brings 
it's own advantages and complications over a standard desktop application. The key advantages are 
common to those for any web application, for example, the ability to access anywhere, no download or 
installation necessary and new features or bug fixes are instantly available to all users. 

However, complications arise from the fact that the web browser is sandboxed from the rest of the 
user's desktop: 

• Pull vs. push technology: the web is pull technology, whereas instant messaging needs to be 
able to push new messages and status updates out to their clients. MSG uses long running 
requests to simulate the web's inability to push content to users. 

• Notifications and focus: alerting users to new messages when they may be viewing another 
web browser window can be problematic. Although MSG will attempt to switch focus to alert 
the user, most browsers will simply make the browser window blink in the system bar, to 
notify users that the window requires their attention. 


MSG also overcame an additional challenge not usually faced by other web-based instant messaging 
providers, namely that there are a number of routes into MSG, via the standard MSG web client, MSG 
Alert system tray tool or by being logged in to OpenLeam website. To achieve this flexibility, MSG 
provides an open API, allowing any third party website to embed MSG. 

4 Future 

People don't come to the OU or OpenLeam just for fun: they are heavily time-constrained and need a 
good payoff for any tool that is added to the learning mix. Therefore, for the future development of 
MSG we need to specifically address the tighter coupling of social tools with learning activities in 
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order to overcome the motivation and critical mass problems raised above. Some of the methods we 
intend to use in addressing these issues include: 

• Introduce new ways of grouping users. As previously described, grouping users simply by the 
course enrolments may not be good enough and there are other innovative ways we could 
group users. An example of how we could do this is by using the interests section from the 
users profile to automatically create groups. Users who enter the same interests would be 
grouped together. 

• Study buddy finder. To specifically address the fact that users know little about each other and 
to help users find the right person to speak to, we could use the interests and homepage URL 
from the users profile to automatically populate BuddyFinder keywords and URLs. We are 
already experimenting with this type of integration by leveraging the OU Course Profile 
Facebook App (Hirst 2007), which aims to create a 'study buddy' capability by linking 
Facebook users who share Open University and OpenLeam course profiles. 

• Integration with FlashMeeting and other tools. Explore the benefits of integration with 
FlashMeeting, the voice/video group interaction tool that is also being made available across 
all of OpenLeam, and use the combination of social software tools provided in OpenLeam to 
gain a better understanding of the role of informal and ad hoc interactions in a large-scale 
learning environment. 

• Encourage development of learning materials. Create sample learning materials which include 
the use of group and collaborative activities which the social tools (MSG, FlashMeeting and 
Compendium) can be used to support. 

Developments such as these will give us several new areas for investigation, and we can begin to 
answer some of the following questions: 

• Will the chat messages begin to move from meta-level-chat to object-level-chat? 

• How important is location to distance learners? 

• Will changes to how users are grouped and the introduction of a study buddy finder increase 
the chances of users 'finding the right person' to chat to? 

• Is closer tool integration (for example with FlashMeeting and Cohere) important for users? 


We are excited at having been able to develop a tool that is Open Source, and integrates location 
information with a mn-anywhere web application, as well as being embeddable in other web sites. 
Students working alone can already find cohorts via Facebook, MySpace, and the many IM tools 
already on the market, but it is dual nature of tight coupling (with OpenLeam) and openness (to other 
environments) that creates both a tightrope walk and an exciting opportunity for interesting research 
into socially mediated learning. 


5 References 

Eisenstadt, M., Komzak, J. and Cerri, S. (2004). Enhanced Presence and Messaging for Large-Scale e- 
Learning, Proceedings of TelEduc04, the Third International Symposium on Tele-Education and 
Lifelong Learning, Havana Cuba, November 2004. 


12 


JIME http://jime.open.ac.uk/20Q8/Q2 



Hirst T., Green- Hughes L., Brown, S. (2007). Open University Course Profiles Facebook App, 
Accessed online on 29 Nov. 2007 at: http://blogs.open.ac.uk/Maths/aih59/010855.html 


Johnson, R. T., & Johnson, D. W. (1986). Action research: Cooperative learning in the science 
classroom. Science and Children, 24, 31-32. 

Nardi, B.A., Whittaker, S., Isaacs, E., Creech, M., Johnson, J., and Hainsworth, J. (2002). Integrating 
communication and information through ContactMap. Communications of the 
ACM, 45(4) 

Vogiazou, Y., Eisenstadt, M., Dzbor, M., and Komzak, J. (2005). From BuddySpace to CitiTag: 
Large-scale Symbolic Presence for Community Building and Spontaneous Play, Proceedings of the 
ACM Symposium on Applied Computing, Santa Fe, New Mexico, March 13 -17, 2005. 

Whitelock, D., Romano, D. M., et al. (2000). Perfect Presence: What does this mean for the design of 
virtual learning environments! , Education and Information Technologies 5(4): 277-289. 


13 


